Generally, digital calling systems allow users or system administrators to include applications in communications sessions. These applications can complete various tasks, for example, record the call, obtain information, provide caller information, etc. In some communication systems, the applications may be sequenced, which typically requires the applications to be placed “back-to-back” in the call topology. As such, communications in the call, including the call data and administration messages, are sent through each application in sequence. In many instances, the applications in the sequence are referred to as Back-to-Back User Agents (B2BUAs).
Unfortunately, there are problems with utilizing B2BUAs. In a call with three or more communication endpoints and during a call transfer, the B2BUAs involved in a call transfer can render the transfer call flows, described in Request for Comment (RFC) 5589, inoperable. The Session Initiation Protocol (SIP) standards commonly expect complete visibility of the dialog information from endpoint to endpoint. Many complex call features, like call transfer, rely on the visibility of the dialog information. Unfortunately, the B2BUAs break the call flows that are based on the assumption that the dialog information is visible. For example, the B2BUAs may change the Contact Uniform Resource Identifier (URI) and dialog IDs on messages before sending them to the next B2BUA or other system component. This behavior renders the Refer-To: URI/dialog ID unusuable by a transferred endpoint.
While it is true that the far-end identity information is maintained in the Request URI, To, P-Asserted-Identity, and From headers of the original INVITE message, these headers are not sufficient to address a particular device. RFC 5589 dictates that transfers utilize the Contact URI and the primary dialog ID. Because this information is altered by the B2BUAs, transfers become problematic.
Prior solutions attempt to have a primary B2BUA (sometimes referred to as a call manager) intercept the REFER and effect the transfer itself by Re-INVITING the transferred/transfer target UAs so they end up talking to each other. This has the unfortunate side effects of: leaving sequenced B2BUAs for the transferring party in the signaling path after that transferring party has dropped from the call; and obscuring the transfer call flow from other sequenced B2BUAs, such that it is not easy to discern that a transfer has occurred.